home *** CD-ROM | disk | FTP | other *** search
- Path: news.crd.ge.com!rebecca!rpi!not-for-mail
- From: ranjit@fwasted.zk3.dec.com (Ranjit Mathews USG)
- Newsgroups: comp.lang.c++,comp.lang.c++.moderated,comp.object
- Subject: Re: C++ objects in shared memory
- Date: 9 Apr 1996 08:49:33 -0000
- Organization: Digital Equipment Corporation
- Sender: cppmods@netlab.cs.rpi.edu
- Approved: devitto@ferndown.ate.slb.com
- Message-ID: <4kd8at$mbr@netlab.cs.rpi.edu>
- References: <4k1ooa$lru@netlab.cs.rpi.edu>
- NNTP-Posting-Host: netlab.cs.rpi.edu
- X-Original-Date: 9 Apr 1996 04:25:11 GMT
-
- I think I've read that Sun C++ offers the capability for compiling libraries
- in such a way that library functions appear at the same virtual address in each
- of several processes into which the libraries are linked. I've read a posting
- claiming this, so I'm surprised to hear you say that this cannot be done on
- Solaris. But then, you might be right and the other posting might've been wrong.
-
- You could try to use RTTI to identify the type of the object and use the
- object's copy constructor to create another object of the same type. You could
- use a letter-envelope idiom to avoid copying data members (you copy only the
- reference to the data in shared memory). I haven't used RTTI, so readers may
- feel free to correct me if RTTI can't be used in this manner.
-
- Alternately, you could write a loader program that has the class library built
- into it. Suppose you want programs A & B to map a shared memory segment at a
- given address and want B to use objects constructed by A in shared memory.
- Let's call the loader L. Create executables A' & B' linked with the linker
- options necessary to ignore unresolved references to the shared library.
- Let the loader fork itself twice. Each of the child processes has the library
- functions at the same virtual addresses. Now, dynamically load A' into the
- first child, using sbrk to allocate memory for loading A' and ld to
- incrementally link A' against the library contained in child 1. Do likewise for
- B'. Now you have two processes A & B, both of which have class library
- functions mapped to the same virtual addresses.
-
- Refer to Jim Coplien's book for coding examples to the techniques described
- above.
-
- In article <4k1ooa$lru@netlab.cs.rpi.edu>, Tony Confrey <ac11@gte.com> writes:
- |> Apologies if you've already seen this, I'm unclear if my newsreader
- |> is set up correctly.
- |>
- |> I am trying to store instances of C++ objects in shared memory so
- |> that their function and data members can be accessed by multiple
- |> processes running on the same unix box.
- |>
- |> Storing the instance in shared memory is no problem - I've been using
- |> placement new with a previously allocated block of shared memory that
- |> all processes connect to. Calling member functions, in particular
- |> virtual member functions, is more difficult.
- |>
- |> I'm finding (actually more like deducing) the following: If process
- |> A creates an instance then the vtbl points to function addresses in
- |> process A's address space. Calling non virtual functions or
- |> accessing data members from another process, B, works fine.
- |> However calling virtual functions from B segv's because its
- |> trying to call outside its address space.
- |>
- |> For a while it looked like linking the class library as a shared library
- |> would work - in fact it does under aix - because the functions end up in
- |> the same place in memory. However under solaris the address spaces are
- |> mapped differently.
- |>
- |> Any suggestion would be appreciated. Can this be done? Is there some
- |> other approach I should take? I find it hard to believe that no
- |> one has ever tried such a thing.
- |>
- |> Thanks
- |>
- |> Tony
-
- { Extra mod sig. trimmed. -mod}
-
- [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
- [ Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm ]
- [ Moderation policy: http://www.connobj.com/cpp/guide.htm ]
- [ Comments? mailto:c++-request@netlab.cs.rpi.edu ]
-